The use of computer software to automatically generate computer programs for performing a prescribed process is often called automatic code generation. Automatic code generators have two main advantages. First, they eliminate the need for the user to know the details of the computer language in which the code is written. Next, they generate reliable code without errors.
The present invention is specifically directed at generating computer software for complex real-time control systems, and particularly multi-rate systems. multi-rate system is a system which needs to simultaneously perform at least two (and typically a multiplicity of) tasks at different rates. The tasks to be performed will frequently include asynchronous events that should be triggered and executed in an asynchronous manner. As will be more fully described below, prior art automatic code generators result in software controllers that do not execute asynchronous events in an asynchronous manner. Instead, these software controllers execute asynchronous events according to a synchronous schedule. It would be highly desirable to provide a method and apparatus for constructing a software controller that executes asynchronous events in an asynchronous manner, thereby obviating the need to synchronously schedule such events.
FIG. 1 shows a prior art apparatus corresponding to U.S. Pat. No. 4,796,179 (the '179 patent), which is assigned to the assignee of the present invention, and which is expressly incorporated by reference herein. Specifically, FIG. 1 depicts a controlled multi-rate real-time system 20 that generates measurement and feedback signals that are applied to a multi-rate digital real-time controller 22. The multi-rate digital real-time controller 22 may be implemented in the form of a general purpose computer that includes standard interface devices for communicating with the multi-rate real-time system 20. The controller 22 executes control software 24. Execution of the control software 24 by the controller 22 results in control signals that are communicated back to the multi-rate digital real-time system 20. The general interactions between a multi-rate real-time system 20 and a multi-rate digital real-time controller 22 are known in the art. Similarly, execution of control software 24 on a real-time controller 22 is known in the art. Attention presently turns to the code generation system 26 disclosed in accordance with the '179 patent.
The code generation system 26 is a general purpose computer (not shown) that executes various software modules, including a software interface 28, which is used to generate a functional description 30 of the multi-rate real-time system 20. Specifically, a human operator interacts with the software interface 28 to create a functional description 30 of the multi-rate real-time system 20. The code generation system's general purpose computer stores the functional description 30, functional library 32 and an automatic code generator 34. In addition, a general purpose computer may be used as the multi-rate digital real-time controller 22.
Instead of relying upon a conventional computer language to functionally describe the controlled multi-rate real-time system 20, the preferred embodiment in the '179 patent, and the present application, is to rely upon functional diagrams that use logic and circuit-like functional elements to describe the relationship between the system's input signals and its output signals. The functional description 30 is obtained by selecting functional elements from a functional library 32 using a software interface 28. Each functional element performs a selected function. FIG. 2 depicts a functional block description for a missile roll control system. The depicted graphic representation has a corresponding data base representation which is described in detail in the '179 patent.
The diagram in FIG. 2 includes three large blocks 36, 38, and 40, called superblocks. Superblocks are used to organize complicated computations into manageable segments. Each superblock 36, 38, and 40 contains one or more descriptive blocks which can be either functional blocks such as the GAIN block 42, or other superblocks such as the ROLL superblock 38 inside the CONTRL superblock 36. All the superblocks except for the main superblock (CONTRL in this example) are used to specify sets of functional blocks for use elsewhere in the functional description.
For each superblock there is specified a timing or sampling interval and a skew (noted as "1st Sample" in FIG. 2). The timing interval specifies both the rate at which the inputs and outputs to the superblock are updated and the rate at which the computations for the functional blocks in the superblock are repeated. The skew specifies the delay before the first sample and first computation cycle for the superblock.
The functional blocks in the library 32 each define a software template for generating a set of software statements. These software statements perform the functional blocks' computations when the control software is executed.
The functional description 30 of the controlled multi-rate real-time system 20 is processed by the automatic code generator 34 which includes an analyzer 44 and a code generator 46. The operation of the automatic code generator 34 is disclosed in relation to FIG. 3. As illustrated in the figure, the functional description 28 is conveyed to the analyzer 44. The first step performed by the analyzer 44 is to generate data structures which represent the flow of data between functional blocks (block 50). Appropriate data structures are described in detail in the '179 patent. Next, the functional blocks are organized into subsystems (block 52). Each subsystem includes all the computations to be performed at a particular sample rate and skew, or in the case of asynchronous events, which are triggered by the same trigger condition. The analyzer 32 then links signals flowing between subsystems and links signals flowing between blocks within each subsystem (block 54). The final step performed by the analyzer 32 is to determine the order of computations within each subsystem (block 56).
Data structures including the information generated by the analyzer 44 are then processed by the code generator 46. The first step associated with the code generator 46 is to relink subsystems (block 58). This step maps out the space needed for each subsystem to communicate with a software bus. The software bus interconnects the control software's subsystems. The software bus is a buffer or data structure through which all data transfers are passed. For instance, if a second subsystem needs certain predefined data from a first subsystem, the data is copied from a portion of the software bus used to hold the first subsystems's outputs to a portion of the bus used as an input buffer to the second subsystem. The relinking step (block 58) also generates data structures which are used by the code generator 44 to determine which signals need to be copied into the sample and hold buffers of the various subsystems. At the beginning of each subsystem's computation cycle all the inputs to that subsystem from other subsystems are "sampled and held", i.e. copied into a buffer. This ensures that these input values do not fluctuate during the time it takes to perform the subsystem's calculations.
FIG. 4 depicts a sample and hold buffer 62 and its relationship to a superblock 64 including sub-blocks 66, 68, and 70. The output of the superblock 64 is conveyed to a zero order hold buffer 72. A zero order hold buffer is a device (i.e., a software technique) used to insure that the outputs from each subsystem are passed to other subsystems only after all the computations for a particular computation cycle are complete. In other words, the zero order hold buffer ensures that all the outputs from a subsystem are internally consistent and not in a state of flux. Thus, the zero order hold buffer makes the outputs of each subsystem piecewise constant--all of the subsystem's outputs change simultaneously and change only at predefined times. The problem with prior art systems that rely upon zero order hold techniques is that intermediate system values, say the outputs of block 68, are not available until all the processing associated with the superblock 64 is completed. Thus, in this scheme, an asynchronous function can only be handled after the zero order hold buffer has received its values. This only occurs after all processing associated with the functional superblock 64 is completed. As a result, the asynchronous event is effectively a scheduled event that is executed only after the predetermined period of time associated with the completion of some other functional operation.
Thus, to handle asynchronous events in a truly asynchronous manner, it is necessary to utilize intermediate system values and eliminate buffer latency delays. Therefore, it would be highly desirable to provide a methodology for exploiting intermediate system values so as to allow asynchronous execution of asynchronous events. Such a system should also eliminate buffer latency delays.
Returning to FIG. 3, after the subsystems are relinked, code is generated (block 60). That is, the code generator uses the previously generated data structures to generate a set of software modules which together comprise the control software 24.
The foregoing process is further described in relation to FIG. 5. FIG. 5 illustrates the software modules and the corresponding data structure outputs associated with the processing of prior art code generation systems. As previously indicated, the software interface 30 is the software that is used to author a functional description of a system. The output of the software interface 30 constitutes the previously described functional description 28 of the controlled multi-rate real-time system 20. As previously described, the functional description is then processed by the analyzer 44 which yields a linked database of functional operations organized into subsystems 80. The code generator 46 includes a subsystem relinker 82 performing the function described in relation to block 58 in FIG. 3. This results in the previously described software bus 90. Subsequently, a control software generator 84 is invoked to execute the function associated with block 60 of FIG. 3. These operations result in the control software 24.
As shown in FIG. 5, the control software 24 includes an initializer 94 for declaring and initializing software elements. The program also includes a scheduler 96 which constitutes the main body of the program. In the course of the scheduler's 96 operation, subsystems are called, as indicated by blocks 98 and 100. The scheduler also invokes an error handler 102. Data communication in the control software 24 is handled over the software bus 90.
The foregoing description provides a general overview of automatic code generation techniques for a controlled multi-rate real-time system. Specific details associated with the operation of the system are available in the '179 patent. Attention presently turns to how the system of the '179 patent would handle asynchronous functions or events. As used herein, asynchronous functions, also called trigger tasks or trigger events, are non-periodic events that are initiated when a trigger condition is satisfied.
In reference to triggered tasks, the '179 patent, at column 40 teaches the following: "While trigger tasks have been discussed above, the preferred embodiment does not handle trigger tasks. However, the addition of trigger tasks to the preferred embodiment would be done as follows. First, superblocks would be flagged as using either a trigger condition or a periodic computation rate. The sample period parameter would still be specified to indicate the priority that should be given to the subsystem task incorporating the superblocks using the trigger condition. The skew parameter would be used to specify the trigger condition for the subsystem by providing an index into a library of available trigger conditions. The main other change needed would be to upgrade the scheduler to test for trigger conditions and to initiate the execution of triggered subsystem tasks. The Start.sub.-- Table mechanism could be expanded, or a separate array for triggered subsystems could be provided, to indicate when triggered subsystems are to begin execution."
The processing methodology associated with such a system is depicted in FIG. 6. FIG. 6 depicts the sequence of operations executed by control software constructed in accordance with the prior art. The first step associated with the control software 24 is to initialize the system (block 110). This step is performed by the main/initializer 94 shown in FIG. 5. Thereafter, discrete functions or tasks are scheduled (block 112) by the scheduler 96 shown in FIG. 5. The scheduling of discrete tasks is coordinated in conjunction with a timer interrupt. The timer interrupt establishes a time base for scheduling tasks. For example, assume that the timer interrupt is set at a 1 ms (millisecond) cycle. In this case, a 4 ms periodic event (block 114) will be executed after 4 timer interrupts.
FIG. 6 also shows functional block 116 which is a 10 ms "enabled" functional block. This means that the function of the block is executed every 10 ms if an enable signal from another functional block is provided. FIG. 6 also shows a periodic function that is executed every 15 ms. Scheduling periodic discrete functions is a relatively straight forward process.
Efficient processing of a triggered task is more difficult. The triggered task must be scheduled for performance. Thus, as indicated in FIG. 6, when a triggering event occurs, a request for scheduling is made to the scheduler. The triggered or asynchronous event is then processed according to a schedule. A determination as to when to process an asynchronous event may be assisted by associating a triggered function with a priority. The priority may be established through an assigned periodic value. For example, a triggered function may be given a period parameter of 3 ms, in which case the scheduler would execute the function as if it were a periodic function to be performed after three timer interrupts. Another way of looking at a triggered function is to view it as an enabled function. In other words, the triggering condition is equivalent to an enable signal. Thereafter, the period value is used to schedule when the function is executed. In either event, the triggered or asynchronous event is not handled in an asynchronous fashion. That is, the asynchronous event is merely scheduled and executed as any other periodic event. It would be highly desirable to execute asynchronous functions in an asynchronous manner.